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ABSTRACT 


Recent  research  in  the  software  engineering  field  nas  produced  a 
number  of  tecnnlques  or  ratlonals  for  structuring  tne  understanding  of 
systeas.  Many  of  these  techniques  are  applicable  to  tne  design  of 
embedded  computer  systeas  and  produce  designs  whose  structures  are 
easily  expressible  in  the  Ada  language.  The  Ada  language  has  a  structure 
which  allows  the  design  of  systems  to  be  expressed  Independently  of  Its 
iableaentatlon  and  thus  can  be  a  good  system  design  language  tor  use 
with  these  techniques. 

This  oaoer  describes  the  software  design  problem  in  the  development 
of  embedded  computer  systems  and  shows  how  the  Ada  language  can  be  used 
as  a  system  design  language  as  well  as  a  system  Implementation  lanauage 
to  alleviate  these  problems.  The  essential  point  of  this  paper  is  that 
uslna  Ada  as  a  system  design  language  encourages  the  designers  to  use 
the  recently  developed  techniques  and  theory  to  develop  better  structures 
for  their  systems  and  then  Implement  the  systems  In  the  same  language 
thus  preserving  that  structure  in  the  product. 
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I.  Introduction. 

In  response  to  tne  explosive  growth  in  the  cost  of  development 
end  eelntenence  of  software  systems,  there  have  been  a  large  number 
of  theories  and  techniques  developed  m  the  area  of  software  design 
and  development.  Some  of  these  are  structured  programming,  top-down 
design  and  Implementation,  structured  analysis  and  deslgn(2l), 
stepwise  refinement (23),  Information  hldlng(lS)  and  programming  teams 
and  walkthroughs (24).  The  central  aim  of  all  of  these  is  to  provide 
Intellectual  control  of  a  design  by  a  systematic  decomposition  and 
abstraction  of  the  problem  into  component  modules  and  composition 
of  these  modules  Into  the  system. 

while  most  of  these  techniques  have  produced  Impressive  results, 
with  measured  qalns  of  4-6  times  Increase  in  produetlvlty(2)  not  being 
uncommon,  tne  i*se  of  these  techniques  In  the  embedded  systems  area  has 
been  limited.  The  reasons  for  this  are  varied.  Some  are  technical  sueh 
as  lack  of  a  suitable  high  level  language  and  the  techniques  and 
compilers  to  go  with  them.  However,  other  reasons  are  psychological 
as  for  Instance,  that  the  time  to  Investigate  deslqn  techniques  and 
to  learn  to  use  a  new  language  Is  viewed  as  not  affordable  during 
these  normally  time  constrained  developments. 

The  technical  barriers  to  the  use  of  modern  software  engineering 
tneorles  and  techniques  are  being  overcome  with  the  Introduction  of 
a  language  and  techniques  specifically  designed  for  embedded  computer 
applications.  This  paper  addresses  the  effects  of  the  Department  of 
Defense's  Ada  language(l)  on  the  design  process  for  embedded  systems. 

One  of  the  reasons  that  the  Ada  language  Is  so  important  to  the-  design 
process  Is  that  the  Ada  language  is  structured  to  allow  it  to  be  used 
as  a  system  design  language  as  well  as  a  programming  language.  A  system 
deslqn  language  (SDL)  is  a  formal  means  of  documenting  the  structure  of 
the  design  of  a  system  without  the  necessity  of  providing  or  referlng  to 
an  implementation  of  the  system.  Ada  provldas  this  means  by  separating 
the  specifications  of  the  components  from  their  Implementations  and  by 
allowing  Interconnection  of  components  only  by  those  means  documented 
In  the  specifications  of  the  components. 

One  of  the  main  themes  of  this  oaper  Is  thmt  the  constraints  on 
the  system  structure  imposed  by  the  use  of  the  Ada  language  as  the 
means  for  documenting  the  system's  design  not  only  cause  the  system's 
design  and  implementation  to  be  easier  but  also  cause  the  resulting 
system  to  be  more  maintainable.  Additionally,  the  use  of  Ada  as  both 
the  design  and  implementation  language  causes  the  documentation  of  the 
system  to  be  more  controlable  since  the  major  part  of  the  documentation, 
evgn  at  the  design  level,  is  the  system  (le.  the  program)  itself. 

One  of  the  main  criteria  used  In  the  design  of  tne  Ada  languaoe 
was  that  the  language  should  aid  In  the  design  of  reliable  systems(5,22) . 
This  criteria  led  to  the  Incorporation  of  modularization  by  packaging 
of  named  entitles  as  the  main  basis (20)  for  structuring  of  software 
systems,  in  addition  Ada  provides  a  distinct  separation  of  the 
specification  of  tne  visible  named  entitles  of  the  module  from  the 
Implementation  of  the  module.  This  allows  the  structure,  or  the 
architecture,  of  the  system  to  be  documented  as  tne  Interconnection 
of  the  Interfaces  of  the  nodules  without  reference  to  tne  implemen¬ 
tations  of  the  modules.  The  use  of  Ada  as  a  system  design  language 
Is  a  result  of  tnis  ability  to  document  the  structure  of  a  system 
using  only  the  specifications  of  packages  and  their  interconnection. 


II 


Modularization 


The  worlds  of  mechanical  design  and  electronic  system  design  have 
long  used  the  concept  of  modularization  and  have  well  developed  methods 
of  documenting  designs  In  terms  of  their  component  modules*  le.  blueprints 
and  schematic  drawings  respectively.  Ada  provides  a  means  of  documenting 
software  designs  and  communicating  those  design  to  others  which*  when 
supplemented  with  Its  equivalent  graphic  drawing*  Is  the  equal  of  the  more 
mature  documentation  methods  mentioned  above*  It  is  the  equal  because  the 
basis  Is  the  same.  The  basis  is  that  a  design  is  represented  as  an 
Interconnection  of  the  Interface  eharaeterlstlets  of  components.  This 
Interconnection  Is  a  model  of  a  well  structured  understanding  of  the 
system(2t).  It  Is  the  Interface  characteristics  which  actually  define 
the  components  which  are  used  In  the  design  because  tne  interface 
characteristics  are  all  tnat  the  user  of  the  component  needs  to  use  the 
component  and  all  that  the  designer  of  the  component  needs  to  build  the 
component (18). 

The  view  of  modularization  embodied  In  Ada  has  evolved  slowly  over 
the  past  decade.  The  main  reason  for  this  slowness  is  tnat  of  the  two 
means  of  modularization*  decomposition'  and  abstraction*  decomposition 
was  viewed  as  the  method  of  modularization  while  abstraction  was  viewed 
as  a  mental  tool  rather  tnan  as  a  language  supportable  mechanism.  In  view 
of  the  way  a  programming  language  influences  the  way  that  oeople  think 
about  systems  and  vice  versa*  this  was  both  the  result  and  the  cause  of 
the  structure  of  earlier  high  order  languages  such  as  Fortran*  Cobol  and 
Alaol.  in  systems  built  In  these  languages*  the  interconnection  of  the 
major  sub-tasks  of  the  system  was  viewed  as  the  responsibility  of  the 
operatlno  system  functions  such  as  linkage  editing  and  the  system 
generation  process.  The  Interconnection  of  the  smaller  parts  of  the 
systems  built  In  these  lanauages  was  through  the  use  of  global  or  common 
data  accessed  by  the  subprograms  from  which  the  systems  were  constructed. 

Modularization  by  abstraction  nad  Its  roots  in  tne  virtual  machine 
concept(6)  and  has  been  Influenced  by  most  of  the  major  advances  made 
by  software  engineering  researcn*  eg.  the  data  typlno  mechanism  of 
Pascai(l4),  Information  hldlng(l8*19)*  abstract  data  types(7*8)  and 
module  interconnection  languages(4).  The  consensus  aeveloDed  In  the 
research  results  Is  that  av software  system  can  and  should  be  designed 
and  constructed  as  an  Interconnected  network  of  software  objects  of 
abstract  data  types.  Abstract  data  types  are  constructed  out  of  a  set 
of  values*  which  may  be  a  complex  composite  of  simpler  values*  and  a 
set  of  operations  which  is  applicable  to  the  values*  with  no  otner 
operations  allowed.  Each  of  tne  objects  of  these  types  Is  to  represent 
(encapsulate)a  particular  logical  entity  such  as  a  design  declslon(l8) 
or  a  related  set  of  properties  of  a  logical  ltem(7). 

A  graphical  representation  of  a  system  modularized  in  this  way  Is 
shown  In  FIG  la.  This  system  prints  reports  from  local  flies  or*  If  the 
report  Is  not  available  In  the  local  files*  the  report  manager  requests 
It  from  remote  files  and  prints  It  when  it  has  been  copied  to  the  local 
files.  The  explanation  of  this  diagramming  method  Is  In  FIG  lb  which  Is 
a  diagram  of  a  single  generle  module  where  the  abstract  type  or  object 
Is  indicated  by  tne  named  box  and  the  resources*  ea.  types*  functions 
etc.*  which  ere  provided  by  the  module  end  those  whicn  are  required  oy 
the  module  are  indicated  oy  the  outgoing  arrow  and  tne  incommlng 
arrow  respectively. 
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The  Ada  language  encourages  this  style  of  design  by  having  packaging 
of  data  and  procedures  as  its  large  scale  structuring  mechanism,  in  the 
system  dlaorammed  In  FIG  la,  each  of  the  modules  becomes  a  package  in  Ada. 
For  example,  the  files  module  in  FIG  la  which  provides  access  to  tne  local 
file  system  is  specified  In  Ada  as; 


package  FILES  is 

type  FILE  18  8TRING02)  I 
type  LINE  is  STRINGC80); 
procedure  REAO(Fi In  FILEiLsout  LINE); 
procedure  WRITECFiln  FXLEiLsln  LINE); 
procedure  RESERVCCFHn  FILE); 
procedure  RELCASECFiln  FILE); 
end  FILES; 


Since  a  programming  language  influences  the  way  that  people  think  about 
systems,  the  use  of  Ada  over  a  period  of  time  leads  tne  designers  to  the 
use  of  abstract  data  types  as  a  natural  way  to  visualize  system  designs. 


XXI.  The  Ad*  Language, 

The  Ada  lanouage(l)  was  designed  with  three  soeeifle  goals: 

1. reliability  and  maintainability,  2, recognition  of  programming  as 
a  human  activity  and  a.efflelency.  The  first  two  of  these  criteria 
drove  the  structure  of  the  language  and  its  intended  use  while  the 
last  filtered  the  possible  Inefficient  structures  from  the  language. 

The  following  is  a  brief  overview  of  the  important  features  of  the 
Ada  language.  The  Ada  language  reference  manueld)  should  be  consulted 
for  a  more  thorough  understanding  of  the  language. 

Program  units. 

Ada  Is  designed  to  encourage  modularization  and  the  accompanying 
ability  to  factor  and  compose  a  system  from  separately  built  parts.  In 
Ada,  a  program  is  composed  from  program  units,  which  are  subprograms, 
packages  (which  define  collections  of  entitles, le.  named  items),  or  tasks 
(which  define  concurrent  or  parallel  computations).  Caen  of  these  program 
units  Is  made  up  of  two  parts:  a  specification,  which  contains  those 
entitles  that  are  visible  to  other  program  units  thus  defining  the  external 
characteristics  of  the  unit,  and  a  body,  which  contains  the  implementation 
of  these  entitles  and  Is  not  visible  toother  units.  Units  and  tnelr  parts 
are  separately  compilable. 

This  seoaratlon  of  the  specification  and  the  Implementation  parts 
of  modules  along  with  the  ability  to  separate  compile  these  parts  allows 
and  encourages  ooth.jtne  construction  of  systems  from  separately  built 
parts  and  the  construction  and  use  of  libraries  of  generally  usable 
component  modules. 

Program  unit  specifications. 

The  program  units  from  wnlch  Ada  programs  are  consrtueted  are: 
subprograms,  packages  and  tasks.  Program  unit  specifications  are  named 
declarations  whlcn  provide  the  types,  objects  and  operations  which  can 
be  used  by  other  program  units. 

Subprograms  are  tne  basic  unit  for  expressing  algorithms  and  provide 
the  means  for  naming  definable  actions.  The  two  kinds  of  subprograms  are 
procedures  and  functions.  A  procedure  provides  the  series  of  actions, 
defined  in  Its  body,  whenever  It  Is  Invoked.  It  may  have  parameters  to 
pass  Information  into  Itself  or  back  to  its  Invoker.  A  function  is  a 
named  activity,  or  operation,  which  computes  a  value.  It  is  similar  to 
a  procedure  but  returns  a  value  as  the  result  of  Its  being  invoked  in 
an  expression. 

Packages  are  the  units  for  encapsulating  collections  of  logically 
related  data.  Packages  define  sets  of  related  types,  data,  operations 
or  subprograms.  Only  those  entitles  which  are  defined  in  the  visible  or 
specification  part  of  the  package  are  allowed  to  be  used  by  other  units. 

The  lmoiementatlon  of  the  visible  entitles  is  hidden  In  the  body  of  the 
package. 

Tasks  are  the  program  units  for  defining  operations  or  procedures 
which  execute  in  parallel  with  other  tasks.  Tasks  define  entries  which 
are  the  synchronized  operations  provided  for  use  by  other  tasks.  Multiple 
Instances  of  tasks  or  dynamic  tasks  can  be  declared  as  objects  of  task 
tyoes.The  languaoe  allows  tasks  to  be  Implemented  on  multiprocessors, 
multlcomputers  or  to  be  interleaved  on  a  single  processor. 


Program  unit  bodies 


Program  unit  bodies  consist  of  a  declarative  Dart*  which  declares 
the  entitles  which  can  be  used  in  the  unit*  and  a  seauenee  of  statements* 
wnlcn  defines  the  Implementation  of  that  program  unit's  actions.  These 
named  entitles  which  can  be  used  by  the  sequence  of  statements  Include 
tyres,  objects*  exceptions  and  other  nested  program  units. 

The  sequence  of  statements  describes  the  unit's  actions.  The 
statements  can  Include  assignment  of  values  to  variables*  procedure  calls 
and  structuring  constructs.  The  structuring  constructs  Include  "lfM  and 
"case*  statements  for  selection*  "while"  and  "tor"  loops  for  Iteration 
and  blocks  for  temporary  declarations  and  actions. 

Tasks  are  constructed  with  the  statements  described  above  supple* 
mented  with  real  time  and  syneronlzatlon  statements.  These  Include  the 
"delay"  statement*  the  "entry"  declaration  for  providing  services  to 
other  tasks*  and  the  "select"  and  "accept"  statements  for  controllng 
tne  rendezvous  which  synerohlze  tasks,  in  a  rendezvous*  either  the 
requester  or  the  provider  of  an  action  arrives  at  the  rendezvous  point 
before  the  other.  Tne  one  wnleh  arrives  first  waits  for  the  other,  when 
the  other  arlves*  the  rendezvous  takes  place*  the  action  is  performed 
and  they  both  proceed  with  their  next  statements. 

Exceptional  conditions*  whleh  make  it  Impossible  to  continue  with 
tne  normal  execution  of  tne  program*  are  handled  by  a  sequence  of 
statements  enclosed  In  an  exception  handler  placed  at  the  end  of  the 
proqram  unit,  wnert  an  exception  handler  Is  Invoked*  It  replaces  the 
remainder  of  tnevunlt  wnere  the  exception  occurred.  Exceptions  can  be 
raised  explicitly  In  tne  program. 

Types 

Every  object  and  value  in  the  program  has  a  type.  A  type  consists 
of  a  set  of  values  and  a  set  of  operations  applicable  to  the  values. 

Types  are  divided  into  four  classes;  scalar*  composite*  aceess  and 
private  types. 

Scalar  types  are  both  the  numeric  types (Integer*  fixed  point  and 
floating  point)  and  enumeration  types  which  allow  programmers  to  define 
ordered  sets  of  distinct  enumeration  literals  to  be  used  as  values  in  tne 
program.  Composite  types  provide  the  means  of  defining  structured  objects 
formed  from  related  components.  Two  kinds  of  composite  types  are  arrays* 
wnleh  have  Indexed  components  of  the  same  type*  and  records*  which  nave 
named  components  of  possibly  different  types. 

Access  types  are  used  to  construct  dynamic  data  structures  by 
defining  a  mechanism  tor  accessing  unnamed  objects  which  are  created 
by  allocators.  Both  the  contents  of  the  objects  and  tne  access  values 
to  the  objects  may  be  changed  by  the  program. 

Private  types  are  defined  in  packages  and  only  tnelr  names  are  made 
visible  In  the  specification  part  of  tne  package.  Ail  operations  on  values 
of  private  type  variables  are  defined  in  the  package  and  both  the  structure 
of  the  data  used  to  define  the  type  and  the  algorltnms  which  Implement  the 
operations  are  hidden  In  the  body  of  the  package. 

other  features 

Ada  provides  a  number  of  other  facilities  to  provide  the  program 
designer  with  complete  control  of  the  computer  when  necessary.  These 
Include  representation  of  entitles*  control  of  Interrupts  and  machine 
code  insertion.  Input*output  is  provided  as  a  library  feature  rather  than 
being  built  into  tne  language.  The  language  provides  for  generic  program 
units  to  encapsulate  sets  of  algorithms  applicable  to  various  types. 


*  IV.  System  Architecture  Design. 

The  quality  of  a  system  is  highly  dependent  on  the  language  m  which 
the  system  is  designed  and  the  language  in  which  the  system  is  ouilt.  The 
criteria  in  both  cases  is  similar#  the  ease  with  which  the  requirements 
.  or  problem  structure  can  be  modeled  In  the  design#  in  the  first  ease  and 
I  the  ease  with  which  the  design  can  be  modeled  in  the  implementation  #  in 
the  second  ease.  An  ideal  language  would  allow  both  the  design  and  the 
ImBiementatlon  to  have  a  structure  whleh  is  an  accurate  recording  of  the 
solution  to  tne  problem. 

Almost  all  of  the  current  high  level  languages  discourage  this  sort 
^  of  mapping  of  solution  into  implementation.  These  languages  sole  concern 

|  is  in  the  expression  of  data  and  algorithms  for  a  single  process.  This  is 

fine  for  small  programs  but  Inadequate  for  large  systems.  These  languages 
have  been  refered  to  as  languages  for  programming  in  tne  small(4).  A 
system  design  language  SOL  provides  the  means  for  describing  the  inter¬ 
connection  information  which  is  the  essence  of  system  structuring  and  is 
m  analogously  refered  to  as  a  language  for  programming  in  the  large(4).  Ada 

■  is  the  integration  of  a  language  tor  programming  in  the  small  with  a 

language  for  programming  in  the  large.  As  such  it  fosters  a  transparent 
mapping  of  both  the  requirements  solution  Into  the  design  and  of  that 
design  into  tne  implementation. 

Recent  research  in  the  software  engineering  field  has  produced  a 
number  of  techniques  or  ratlonals  for  structuring  the  understanding  of 
l_  systems.  The  Ada  language  was  designed  to  facilitate  the  representing 

of  designs  produced  using  these  techniques.  Thus  Ada  as  a  system  design 
,w*  language  (SDL)  fosters  the  use  of  these  techniques. 

The  rest  of  this  chapter  will  present  three  methods  of  structuring 
systems  and  snow  now  Ada  documents  tne  resulting  designs.  Tne  three 
methods  are  functional  decomposition^) ,  information  hldlng(l8)  and 
0  abstract  data  types(7).  These  techniques  are  not  used  in  exclusion  of  one 
another  but  ratner  are  complementary  of  each  other.  Tney  are  normally 
used  in  conjunction  with  one  another  tor  the  complementary  tasks  of 
refining  and  enhancing  the  design  during  the  system's  development  process. 

1.  Functional  decomposition. 

■ 

The  functional  decomposition  or  data  transformation  method  of  design 
will  be  illustrated  as  it  appears  in  the  analysis  and  design  technique  of 
structured  analysis.  Structured  analyslsO)  is  a  methodology  whleh  uses  a 
graphical  method  for  functlonaly  specifying  the  structure  of  the  system 
^  being  designed.  This  method  uses  graphs  known  as  "data  flow  diagrams”  in 
»_  conjunction  with  logical  data  descriptions  stored  in  data  dictionaries  to 
model  the  structure  of  the  system.  The  data  flow  diagram  documents  the 
structure  of  the  system  as  the  logical  flow  of  data  items  tnrough  the 
system#  shown  as  labeled  arrows#  and  the  transformations  which  happen  to 
these  data  flows#  snown  as  labeled  circles  or  boxes.  The  structure  of  a 
data  item  is  documented  by  a  logical  definition#  Including  the  naming 
gT  and  defining  of  its  components#  in  the  data  dictionary. 

In  use  the  logical  data  flows  and  data  transformations  are  derived 
in  a  three  step  process.  First  an  existing  or  envisioned  physical  system 
is  modelled#  resulting  in  a  data  flow  diagram  which  is  labeled  with  both 
Physical  data  items  and  physical  transformations.  Zn  the  second  phase 
tne  Physical  model  is  transformed  into  a  logical  model  by  abstracting 
p_  logical  data  flows  and  transforms.  Finally  the  resulting  loqical  model 
is  modified  until  It  models  a  system  which  fulfills  the  requirements. 

The  results  of  this  process  can  be  seen  in  the  following  example 
design  of  a  stoplight  control  system!  The  transformations  of  data  types 
(data  flows)  whleh  taxe  place  in  a  stoplight  system  are  diagrammed  m 
figure  2.  The  presence  or  absence  of  vehicle  in  a  lane  as  ooserved  by  a 
I  detector  is  transformed  into  an  approach  being  either  occupied  or  empty. 
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The  state  of  the  aoproach  Is  transformed  Into  a  request  for  a  green  or 
red  lloht.  This  request  causes  the  light  to  be  set  to  red,  yellow  or  green 
as  appropriate  considering  the  current  state  of  the  system.  Note  that  this 
method  of  decomposition  seeks  first  to  discover,  and  name,  the  logical 
types  of  data  wnich  exist  In  the  system  and  then  name  tne  activities  which 
transform  these  types. 

when  these  data  types  (arrows)  and  their  transformations  (boxes)  are 
named  and  connected,  the  "data  flow  diagram”  shown  in  FIG  2  results.  This 
diagram  can  then  be  used  as  a  basis  to  model  the  structure  of  tne  system 
In  Ada.  This  method  of  design  produces  modules  (transformations)  which  are 
defined  by  the  interfaces  (data  flows)  between  the  modules.  This  structure 
is  easily  transformed  into  Ada  where  the  modules  become  Packages  or  Tasks 
and  the  interfaces  become  the  visible  parts  of  these  modules  (le.  types, 
object,  procedures,  functions  or  entries). 


vehicle  Approach  Request  red 

present  --------  occupied  --------  red  ------ — ----  set  -----  yellow 

-•••—>  I  Detector  I  I  Aoproach  I ----->  I  Intersection  I  ••>  l  Light  |  — — > 

absent  --------  empty  IControl  I  green  I  Control  l  — —  green 


FIG  2. 

This  data  flow  diagram  is  transformed  Into  the  following  design 
which  is  documented  as  the  visible  part  of  an  Ada  orogram(FXG  2).  In 
the  design  the  modules  detector,  approach  control  and  Intersection 
control  have  two  tasks  each,  one  for  each  direction.  The  complete 
system  Is  included  m  tne  appendix. 


procedure  stop.LIGHT  is  —  main  program, 
type  DIRECTION  Is  (N.S,E.W)) 
package  DETECTOR  Is 

task  type  CONTROL.TASK  j  --  is  hardware. 
CONTROL I array (DIRECTION)  of  CONTROL.TASK) 
end  DETECTOR) 
package  APPROACH  Is 

task  tyne  CONTROL.TASK  Is 

entry  APPROACH.OCCUPIED)  -•  Interrupt, 
entry  APPROACH.empty)  «  interrupt, 
end  CONTROL.TASK) 

CONTROL {array (DIRECT ION)  of  CONTROL.TASK; 
end  APPROACH) 
package  INTERSECTION  Is 

task  type  control.task  is 
entry  REOUEST.GREEN) 
entry  REQUEST.RCD) 
end  CONTROL.TASK) 

CONTROL) array (DIRECTION)  of  CONTROL.TASK) 
end  INTERSECTION) 
packaee  LIGHT  is 
task  CONTROL  is 

entry  SFI.TO(COLOR) (DIR*  in  DIRECTION); 
end  CONTROL) 
end  LIGHT) 
end  STOP.LIGHT) 


The  transformation  front  data  flew  diagram  to  program  structure 
(viaible  part  of  Ada  program)  was  straightforward  in  this  ease.  The 
modules  became  packages  and  the  interfaces  became  entries  or  procedures. 
These  entries  or  procedures  become  properties,  or  resources,  of  one  of 
the  modules  which  it  connects. 

Structured  analysis  is  one  of  a  number  of  functional  decomposition 
methodologies  which  derive  the  structure  of  a  system  in  terms  of  the 
transformations  or  functions  on  logical  data  types.  The  transformations 
produce  the  logical  data  types  which  oecur  in  a  system  from  the  system's 
other  logical  data  types,  other  functional  decomposition  methodologies 
which  produce  similar  system  designs  are  SADT(2i)»  H0SC17)  and  data 
directed  decomposltion(16) • 

2.  Information  hiding. 

Information  hlding(18)  is  a  method  of  modularization  in  which  each 
module  nldes  the  lrrelevent  information  about  components  inside  the 
module  while  providing  aceess  to  the  required  information  to  enable  use 
of  the  module.  The  interface  of  a  module  provides  an  abstract  vlew(i9) 
of  the  entity  enclosed  within  it.  The  entities  which  are  enclosed  in 
the  modules  are  tne  design  decisions  which  must  be  made  during  the 
deslan  process. 

To  see  wny  It  is  that  the  design  decisions  are  the  entities  in 
the  modules,  the  rational  for  this  methodology  must  be  described.  One 
of  the  major  fallings  In  the  normal  methods  of  deslaning  systems  Is 
that  they  produce  systems  which  are  expensive  to  maintain.  The  reason 
that  this  is  true  is  that  the  systems  are  difficult  to  change.  Since 
changing  a  system  means  cnanglng  some  design  decision.  It  follows  that 
if  one  wants  a  system  to  ee  easy  to  change  (maintain)  then  each  design 
decision  must  affect  as  little  of  the  system  as  possible  and  there 
should  oe  as  little  coupling  between  design  decisions  as  possible.  - 
This  last  sentence  was  the  rational  which  brought  tne  Information  hiding 
deslan  method  Into  existence.  Restated  it  says  in  order  for  a  system 
to  be  maintainable.  It  should  be  designed  as  an  interconnection  of 
modules  where  each  module  hides  the  result  of  one  design  decision  by 
presenting  for  use  by  the  other  modules  an  abstract  view  of  the  entity 
about  which  that  decision  was  made. 

when  a  system  is  being  designed  using  this  methodology,  certain 
guidelines  are  used  when  maxing  the  design  decisions  which  determine 
the  decomposition  of  the  syktem  into  components.  These  components 
can  then  be  Independently  designed,  and  after  the  system  Is  in  use. 
independently  modified.  Essentially,  the  Information  hiding  guidelines 
are  the  followlng(is): 

t.  rfaxe  a  list  of  all  of  the  design  decisions  for  which 
change  cannot  oe  ruled  out. 

2.  Encapsulate  each  design  decision  in  one  module.  This  means 
that  all  of  the  programs  that  require  the  knowiege  of  the  decision, 
and  on'/  tnose.  comprise  the  module. 

3,  Design  the  abstract  Interface.  This  Interface  consists  of 
the  data  types  and  procedures  that  the  module  users  need  to  be 
able  to  maxe  use  of  the  entity  In  the  module  witnout  knowing  how 
It  is  Implemented. 

as  an  example  of  this  methodology,  in  the  design  of  a  text  editor, 
tne  wav  In  whlcn  the  text  Is  stored  In  the  editor  is  a  design  decision. 
For  instance  the  data  may  be  stored  In  memory. or  it  may  be  stored  on  a 
disx  file,  or  It  may  be  stored  in  virtual  memory.  Also  it  may  be  stored 
as  an  array  or  a  list  of  some  kind.  Therefor  the  entity  to  be  designed 
Is  made  the  contents  of  a  module.  This  module  called  DOCUMEfcT.HULDER  is 
shown  in  FIG  4  as  an  Ada  package  specification  (le.vlslole  part). 


package  DOCUMENT.HOLDER  Is 

type  LIME  Is  5TRXNG(LXNE.LF.NGTH); 
type  LXME.NUMBER  Is  private; 
procedure  CLEAR; 
function  EMPTY  return  BOOLEAN; 
function  NEXT.LINE  return  LINE.NUMBER; 
function  PREVIOUS.LXNE  return  LXNC.number; 
function  FIRST.LINE  return  LINE.NUMBER; 
function  LAST.line  return  LINE.NUMBER; 

Procedure  XMSERT.BEFORE  (LXNE.SUMtln  LINE.NUMBER;  THZS.LXNEtln  LINE); 
procedure  INSERT.AFTER  (LINE.NUMxln  LINE.NUMBER;  THIS.LXNExin  LINE); 
procedure  GET.LINE  (LINE.NUMxln  LINE.NUMBER;  THIS. LINE l out  LINE); 
end  DOCUMENT.HOLDER; 

FIG  4. 

As  can  be  seen  the  Ada  package  specification  Is  just  the  abstract 
interface  needed  for  this  methodology.  This  package  specifies  that 
DOCUMENT.HOLDER  is  a  collection  of  numbered  lines  which  can  be  operated 
on  by  using  tne  procedures  and  functions  and  can  be  Implemented  In  any 
way  as  long  as  the  implementation  provides  the  specified  types,  procedures 
and  functions. 

3.  Abstract  data  types. 

Data  abstraction  is  a  "thought  tool"  as  well  as  a  methodology.  The 
way  in  which  the  designer  of  a  system  approaches  the  design  is  greatly 
Influenced  by  the  language  in  which  he  expresses  designs.  The  availability 
of  data  abstraction  facilities  In  a  system  design  language  like  Ada 
provides  the  designer  with  the  ability  to  modularize  the  system  into  the 
looleal  entitles  (abstract  data  objects)  most  appropriate  to  the  problem 
belgn  solved. 

The  use  of  abstraction  In  the  design  of  systems  Is  one  of  the  main 
ways  of  reducing  the  complexity  In  the  system's  design.  The  reduction  of 
complexity  Is  accomplished  by  concentrating  on  defining  only  the  essential 
logical  characteristics  of  the  system  and  Ignoring  tor  the  time  being,  the 
nonessential  Implementation  details  of  the  system.  This  concentration  upon 
logical  properties  leads  to  the  specification  of  the  system  as  an  abstract 
data  type,  or  object,  consisting  of  the  type  name  and  the  operations  which 
are  associated  with  the  type.  Thus  the  first  step  in  the  design  process 
results  In  the  system  being  specified  as  an  abstract  data  type  In  Ada, 
that  Is  a  package  specification  consisting  of  a  type  declaration  and  a  set 
of  operations  (procedures  or  functions)  applicable  to  objects  of  that  type. 

Once  tne  system  Is  specified,  and  thought  of,  as  an  abstract  data 
tyoe(19),  tne  tyoes  and  operations  needed  to  loglcaiy  implement  the  system 
are  conceived  and  specified  as  abstract  data  types.  This  Is  accomplished 
by  a  process  of  successively  reflnlng(16)  the  data  abstractions  In  terms 
of  other  more  concrete  data  types.  This  successive  refinement  process  Is 
an  iterative  process  whereby  the  abstract  data  types  which  are  needed  by 
tne  program  at  one  level  are  implemented,  or  represented,  as  data  types 
which  are  less  abstract  or  more  concrete  which  are  then  Implemented  in 
terms  of  even  less  abstract  data  types,  etc.  This  decomposition  of 
abstract  data  tyoes  Into  less  abstract  types  continues  until  the  data 
types  needed  are  available  directly  in  the  programming  language  being 
used  to  Implement  tne  system. 


As  an  example,  a  one  pass  assembler  may  be  described  at  the  most 
abstract  level  as  consisting  of  an  assembly  procedure  which  gets  symbols 
from  a  source  file  and  using  a  symbol  table  for  storage  puts  data  and 
instructions  in  an  object  file.  The  structure' of  the  assembler  is  snown 
in  FIG  5.  Each  of  tne  named  boxes  is  an  abstract  data  type. 
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FIG  5 


The  specification  of  tne  abstract  data  type  symbol  table  as 
an  Ada  package  is  shown  in  FIG  6a.  Note  particularly  that  the  symbol 
table  is  not  the  set  of  memory  locations  and  storage  patterns  that  is 
classiciy  thought  of  as  describing  a  table,  but  rather  it  is  a  se.t,  of 
logical  operations  applicable  to  the  type  symbol  taole.  A  significant 
additional  advantage  of  decomposing  systems  into  abstract  data  types 
Is  that  some  of  the  data  types  may  be  generally  useful  in  other  systems. 
Since  the  interface  to  an  abstract  data  type  is  simple,  by  definition 
its  Interface  is  the  minimum  necessary  information  needed  to  use  it, 
the  abstract  data  type  is  the  Ideal  entity  to  build  libraries  around. 

Ah  example  of  a  generally  useful  data  type  is  the  character  buffer 
snown  In  FIG  6b. 


pacieao*  symboii.table  is 

type  SYM.NAXE  IS  new  STRING(20); 
type  SYM.TYPE  is  (INI, FLOAT) 
type  ITEM  is  % 

record 

napeisym.name; 

TYP£tSYM.TYPE; 

LOCATIONIINTEGERf 
end  record! 

procedure  INSERT (SYMBOL! in  ITEM)} 
Procedure  retrieve (name: in  sym.name; 

SYMBOL xout  ITEM); 
notjfound : except ion ; 

—raised  by  retrieve 
end  SYMB0L.TA8LE! 


task  BUFFER  is 

entry  READ(Csout  CHARACTER); 
entry  rfRITE(Ciin  CHARACTER); 
end  BUFFER; 


FIG  6a 


FIG  6b 


4.  Documentation 


A  significant  advantage  of  using  Ada  as  the  means  of  documenting 
tne  structure  of  the  system  is  that  it  is  maintainable  using  the  same 
methods  and  automated  tools  used  to  maintain  computer  programs.  In  the 
case  where  Ada  is  also  the  implementation  language,  the  maintenance  of 
tne  design  documentation  becomes  automatic  slnee  it  is  an  integral  part 
of  the  implementation 

Tne  actual  documentation  of  the  structure  of  the  system  is  contained 
in  the  visible  parts  of  tne  packages  whicn  constitute  tne  specification 
of  the  system.  Since  these  package  specifications  are  textually  nested 
as  required  by  the  language  processor  and  formally  provide  only  the 
syntax  of  the  abstract  data  types,  it  is  wise  to  supplement  tne  Ada 
specification  in  two  ways.  First,  since  people  understand  the  .structure 
of  things  better  when  presented  with  a  graphical  representation,  the 
Ada  text  should  be  supplemented  with  its  equivalent  graphical  rendition 
in  a  form  similar  to  FZC  la. 

Secondly,  slnee  the  Ada  text  provides  only  the  syntax  of  tne 
provided  types  and  operations,  that  text  should  be  supplemented  with 
both  descriptive  semantic  information  and  a  list  of  tne  required  types 
and  operations,  included  as  comments. 

The  system  documentation  should  also  Include  structured  requirements 
specif lcatlonc 12)  in  a  form  compatible  with  the  design  specification.  In 
addition,  tne  development  of  the  requirements  should  benefit  from  the  use 
of  a  structured  analysis  technique  such  as  HOS  (3,17).  A  complete  system 
description  of  the  stoplight  control  system  shown  in  FIGs  2  and  3  is 
included  in  appendix  1  as  as  example  of  the  documentation  of  a  system  . 
Appendix  II  provides  a  syntax  description  of  Ada  as  a  System  Design 
Languaae  (SDL)  and  describes  its  usage. 


V.  System  Component  Design. 

The  design  process  for  tne  tnree  types  of  program  units  is 
basleiy  similar.  This  process  is  oased  on  the  small  scale  structuring 
mechanisms  of  the  Ada  language!  strong  data  typing,  user  definable 
data  types,  structured  control  constructs  and  procedure  or  function 
invocation.  Ada  orovldes  a  strong  typing  mechanism  whereby  every  objeet 
must  nave  a  declared  type  and  conversion  between  objects  of  different 
tyoes  is  not  allowed.  During  compilation,  this  mechanism  catenas  a 
number  of  design  errors  which  oeeur  frequently  in  nontyped  languages. 

Types  in  Ada  consist  of  the  built  in  numeric  tyoes,  enumeration 
tyoes,  where  the  programmer  defines  by  name  the  values  of  tne  type,  and 
certain  built  in  enumeration  types  such  as  boolean  and  cnaracter  types. 
Additlonaly,  Ada  orovldes  user  defined  composite  types  whereby  the 
programmer  can  define  arrays  with  elements  of  the  same  type  and  records 
with  elements  of  different  types.  Ada  also  provides  tne  ability  to 
create  dynamic  objects  of  any  type  by  defining  access  types  to  those 
objects. 

The  control  constructs  consist  of  sequencing  of  statements,  an 
alternative  cnoice  mechanism,  an  iteration  construct  and  procedure 
or  function  invocation.  The  choice  mechanism  consists  of  tnree 
statements,  the  "if  tnen  else"  statements,  the  "ease”  statement  and, 
in  the  case  of  tasks,  tne  "seleet”  statement.  The  iteration  mechanism 
is  the  "looo"  statement  with  a  number  of  termination  methods.  Tne 
basic  loop  is  nonterminating,  however  it  can  be  modified  by  eltner 
a  "for"  statement  to  looo  a  certain  number  of  times,  or  a  "while" 
statement  to  test  for  a  certain  condition  before  each  loop.  The 
procedure  invocation  occurs  as  a  statement  and  the  function  invocation 
oceurs  in  an  expression  thereby  naming  needed  operations  whicn  are 
defined  elsewhere. 


At  the  logical  level,  a  procedure  or  function  defines  a  single 
abstract  event.  A  package  defines  an  abstract  data  type  which  provides 
operations  on  oermanent  objects  of  the  type  when  requested.  A  task  defines 
an  abstract  data  type  but  it  is  active  and  operates  in  parallel  with  other 
tasks  by  either  providing  or  asking  for  operations  with  those  other  tasks. 

A  procedure  implementation,  for  instance  FIG  7,  may  declare  some 
local  types,  objects,  procedures,  functions,  packages  or  tasks.  These 
declared  entities  are  only  visible  within  the  procedure  and  have  a 
lifetime  limited  to  the  current  invocation  of  the  procedure.  Procedures 
provide  only  one  operation  or  event  which  can  be  invoked. 

procedure  SORT  (Alin  INTEGER. array )  Is  -•  bubble  sort 
procedure  EXCHANGE  (LEFT, RIGHT! in  out  INTEGER)  Is 
TEMPI INTEGER! 
begin 

TEMPtmLEri! 

LEFT: *R1GHT> 

RIGHT;*TEMP; 
end  EXCHANGE! 
begin 

for  last  In  reverse  A'RANGE  loop 
for  FIRST  In  A'FIRST. .LAST  loop 
if  A(FIRST)  >  A(FIRSTei)  then 

EXCHANGE  C A(FIRST) , ACFIRST+1 ) ) ! 
end  If! 
end  loop! 
end  loop! 
end  SORT! 

FIG  7 

A  package  Implementation,  for  Instance  FIG  9,  may  also  declare 
some  local  types,  objects,  procedures,  functions,  packages  or  tasks. 

These  declared  entitles  are,  again,  only  visible  within  the  package 
but  they  now  nave  a  lifetime  which  is  not  limited  to  the  invocation  of 
one  of  the  procedures  In  the  package's  visible  part,  but  rather  last  as 
long  as  tne  package  lasts.  Package  specifications  provide  all  of  the 
operations  whicn  are  allowed  to  be  applied  to  the  enclosed  entities. 

package  body  SYMBOL.TABLE  is 

subtype  index  Is  integer  range  i.,200! 

TABLE!  array(lNDEX)  of  ITEM! 
function  first.fr EE  return  INDEX  Is  ...  end! 
procedure  INSERT (SYMBOL! in  ITEM)  is 
begin 

TA8LECFIRST.FREE) i»5TNB0l! 
end  INSERT! 

procedure  RETRIEVE ( NAME | In  5 YM. NAME! SYMBOL  tout  ITEM)  IS 
beqln 

for  i  In  INDEX  loop 

if  NAMEmTABLE(I) .NAME  then 
SYMBOLtsTABLE(I)! 
return! 
end  If! 
end  loop! 
raise  not.found! 
end  RETRIEVE! 

beam 

--  initialise  table 
end  SYMBOL.TABLE| 


FIG  8  (implementation  of  FIG  6a) 


A  task  Implementation  (body)  may,  like  a  package,  declare  local 
types,  objects,  procedures,  functions,  packages  and  tasks,  but  the 
task  can  only  export  entries.  Tnese  loeal  declarations  have,  as  in 
the  ease  of  packages,  a  lifetime  equal  to  that  of  the  task.  The  control 
structures  in  tasks  must  however,  be  supplemented  with  constructs  not 
available  in  procedures  or  packages  since  the  order  In  which  entries  may 
be  called  and  the  syncronlsatlon  with  other  tasks  must  be  represented. 

The  structure  of  control  in  tasks  is  based  on  the  selection  of  those 
entries  which  may  oe  accepted  at  the  current  state  in  processing  the  task. 
In  addition  tne  main  part  of  the  task  body  is  normally  enclosed  in  an 
infinite  loop,  since  tasks  normally  run  until  explicitly  terminated. 

An  example  task  oody  tor  the  task  BUFFER  of  FIG  6b  is  shown  in 
FIG  9  and  a  complete  system  based  on  tasks  is  the  stoplight  system 
shown  in  appendix  I. 

task  body  BUFFER  is 

SIZEiconstant  INTEGER*«iO| 

BUFF ! arr ay (1.. SIZE)  of  CHARACTER) 

SLOTS-FULL* INTEGER  range  0..8IZE*mO; 

WRITE.INDEX, READ-INDEX* INTEGER  range  i..8IZC*ml| 

begin  * 

loop 

select 

When  SLOTS-FULL  <  SIZE  » 

accept  WRITEceiln  CHARACTER)  do 
BUFFCWRITE-INOEX) *«C| 
end) 

WRITE— INDEX *s  WRITE— INDEX  mod  SIZE  ♦! » 

SLOTS-FULL * ■SLOTS.FULL+ 1 I 
or  when  SLOTS-FULL  >  0  «> 

accept  READCOout  CHARACTER)  do 
C:«BUFF(READ.INDEX) J 
end* 

READ-INDEX imREAD-INDEX  mod  8IZE+1; 

SLOTS-FULL I «SL0T5.FULL- 1 | 
or 

terminate* 
end  selecti% 
end  loop; 
end  BUFFER; 

FIG  9  (implementation  of  FIG  6b) 

Tne  small  scale  structuring  mechanisms  in  the  Ada  language  are 
constraints  on  the  structure  of  the  components  from  which  systems 
are  constructed.  Their  purpose  is  not  to  assist  in  the  development 
of  algorithms  but  rather  in  forcing  the  implementation  of  the 
algorithm  to  clearly  display  the  logic  of  the  algorithm  in  terms 
appropriate  to  the  algorithm.  In  addition  these  mechanlnlsms  cause 
tne  information  necessary  to  understand  the  algoritnm,  namely  tne 
information  used  by  the  algorithm,  to  be  highly  localised.  Thus  Ada 
as  a  program  design  language  (PDL)  enhances  the  maintainability  of 
the  components  of  a  system  in  an  analogous  way  to  the  way  Ada  as  a 
System  oeslgn  Language  enhances  the  maintainability  of  the  system. 

Tnat  is,  Ada  enhances  maintainability  by  constraining  structure  so 
tnat  the  structure  of  the  system  (or  program)  eleariy  displays  the 
loqle  of  the  solution  to  the  problem  and  the  information  necessary 
to  understand  any  oart  of  the  system  is  loeal  to  that  part. 


VI. 


Conclusions 


The  use  of  Ada  as  a  system  Design  Language  (SDL)  Imposes  some 
significant  constraints  on  the  modularizations  whien  can  be  used  In 
tne  design  of  systems.  The  imposition  of  these  constraints  Is  the 
source  of  tne  strength  of  Ada  as  the  SDL  In  the  same  way  that  the 
Imposition  of  constraint  on  tne  control  structure  of  programs  Is  the 
source  of  strength  of  structured  programming.  Good  systems  like  good 
programs  nave  a  structure  that  Is  dlseernable  to  the  reader  and 
nave  a  good  localization  of  names  and  concepts  in  tne  component 
oarts.  Thus  tne  structured  programming  and  the  modularization  regulred 
by  Ada  reduces  the  complexlty(17)  of  system  designs  and  implementations. 

The  constraints  which  Ada  imposes  on  designs  are  In  now  one  may 
specify  the  components  from  which  one  can  construct  tne  system  and  how 
tnese  components  can  be  interconnected  to  form  tne  system.  The  specifi¬ 
cation  of  a  component  In  Ada  Is  tne  specification  or  visible  part  of 
an  Ada  package.  This  is  exactly  tne  abstract  interface  (19)  syntdx 
regulred  by  tne  modern  modularization  methods.  A  document  consisting 
of  the  Ada  package  specifications  which  constitute  a  system,  le.  an  SDL 
description,  supplemented  with  its  graphical  egulvalent  is  an  ideal 
formal  design  description  from  the  points  of  view  of  understandablllty 
and  malntainaolllty(lS) •  When  this  design  description  is  implemented 
In  the  Ada  language*  an  additional  twofold  advantage  is  accrued.  Both 
tne  design  and  the  Implementation  mirror  the  structure  of  the  problem 
and  tne  design  documentation  is  automatically  maintained  since  it  is 
an  integral  cart  of  tne  finished  system. 
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APPENDIX  I. 


DESIGN  EXAMPLE!  A  STOPLIGHT  CONTROL  SYSTEM. 


STOPLIGHT  DATA  PLOM  DIAGRAM. 

The  transfornetlons  of  data  typas  which  take  Place  In  a  stoplight 
are  diagrammed  in  the  figure.  The  detection  or  non  detection  of  a 
vehicle  in  a  lane  is  transforaed  into  that  approach  being  either 
occupied  or  eapty.  The  state  of  the  approach  is  transforaed  into 
a  reauest  for  a  green  or  red  light.  This  reguest  eeuses  the  light 
to  oe  set  to  red,  yellow  or  green. 

when  these  data  types  and  their  transformations  are  named  and 
connected*  the  following  "data  flow  diagram"  results.  This  diagram 
can  tnen  be  used  to  model  the  structure  if  the  system.  This  method 
of  design  produces  modules  (transformations)  whose  descriptions 
are  the  Interfaces  between  the  modules.  This  structure  is  easily 
modeled  in  Ada  where  the  nodules  become  Packages  or  Tasks  and  the 
Interfaces  beeome  the  visible  parts  of  these  modules  (le.  types* 
object*  procedures  or  entries). 


Approach  Reguest 

venlele  -------  occupied  red  ----------  set  — — 

— — >  i  Detector  I  1  Approach  I  — — >  I  Intersection  I  — >  I  Light  I 

-------  empty  I  Control  (green  l  Control  l  ----- 


red 

yellow 
— > 
green 


STOPLIGHT  REQUIREMENTS  SPECIFICATION. 


1.  introduction. 

This  reoulrements  specification  describes  e  stoplight  system 
end  Its  components.  The  description  uses  module  descriptions  to 
describe  the  system  itself  end  eech  of  the  hardware  end  software 
components.  Tne  module  descriptions  give  only  the  external 
behavior  (Interface  characteristics)  of  the  system  or  component. 
These  interface  enaracterlstles  are  just  the  visible  behavior  of 
tne  module  and  are  described  independent  of  other  modules  vnlch 
this  module  may  be  connected  to.  This  means  that*  for  Instance* 
hardware  modules  descriptions  refrain  from  desrlblng  the  system 
effects  which  the  module  causes  or  displays,  software  modules 
likewise  refrain  from  describing  their  effect  on  either  the 
hardware  or  other  software  modules  out  merely  the  functions 
tnet  It  provides. 

2.  STOPLIGHT  SYSTEM. 


MODULE  NAME |  STOP-LIGHT 

behaviors  The  stoplight  system  controls  a  signal  at  a  four 
way  Intersection.  It  detects  vehicles  in  an  approach  area  of 
each  approaching  lane  of  the  Intersection  and  provides  a  green 
llont  to  occupied  lanes. 

when  no  lanes  are  occupied  all  lights  are  red. 
when  a  lane  becomes  occupied  the  light  In  Its  direction 
Is  made  green. 

As  long  as  the  lone  remains  occupied  the  llgnt  In  Its 
direction  remains  green.  If  however*  a  lane  In  the  opposite 
direction  becomes  occupied  then*  after  15  seconds*  the  light 
In  the  current  direction  goes  tnrough  yellow  to  red  and  the 
light  in  the  opposite  direction  becomes  green. 

when  a  lanes  In  a  direction  become  empty  the  llgnt  in 
tnet  direction  goes  through  yellow  to  red. 

3.  HARDWARE  modules. 


MODULE  NAME!  DETECTOR » 

BEHAVIOR!  Detects  when  e  lane  approach  becomes  occupied 
and  signals  tnat  its  lane  Is  occupied  Cle.  generates  an 
occupied  Interrupt).  Detects  when  a  lane  becomes  empty  and 
signals  tnat  its  lane  Is  empty  (la.  generates  an  empty 
Interrupt). 

There  are  two  detectors*  one  vnlch  responds  to  lanes 
In  the  nortn-soutn  direction  (the  north  detector  is  ORed 
with  the  soutn  detector)*  and  one  of  which  responds  to  the 
east-west  direction. 

CHARACTERISTIC  VALUES! 

N-S  OCCUPIED  •>  INTERRUPT  AT  LOCATION  8 

N-S  EMPTY  ■>  INTERRUPT  AT  LOCATION  16 

E-*  OCCUPIED  ■>  INTERRUPT  AT  LOCATION  12 

E-w  EMPTY  ■>  INTERRUPT  AT  LOCATION  20 


MODULE  NAME:  LIGHT 


PROVIDES!  Type  COLOR  is  (RED, YELLOW , GREEN) 

LIGHT(N-5,E_W) 

behavior:  LIGHT  &  array(N-s.E.w)  of  three  lamps  with  red, yellow  and 

green  filters.  Each  laap  can  be  on  or  off. 

CHARACTERISTIC  VALUES: 

LIGHT  a  LOCATIONS  76, SO 
RED  b  p  100 
YELLOW  b  b  010 
GREEN  a  b  001 


4.  SOFTWARE  MODULES. 


module  name:  APPROACH. CONTROL 

PROVIDES:  LAvE-OCCUPIED 
LANE-EMPTY 
LOOK— AT (LANE) 

CYCLE 

REQUIRES:  REQUEST-RED 

REQUEST— GREEN 

behavior:  Model  state  (eaoty,  occupied)  of  lane. 

LANE-OCCUPIED  Causes  occupied  t  REQUEST-GREEN. 
LANE-EMPTY  causes  empty  6  REQUEST-RED. 

LOOK-AT  shows  state. 

CYCLE  behaves  like  EMPTY  followed  oy  OCCUPIED. 


MODULE  NAME:  INTERSECTION. CONTROL 

provides:  request.red 

REQUEST-GREEN 

REQUIRES:  LOOK-AT (LIGHT) ,L0QK-AT(LANE) , SET-TO (COLOR) (OIR) , CYCLE 

behavior:  wnen  lights  are  red  REQUE8T.GREEN  causes 
SET-TO(GREEN) (MY-DIRECTION) . 
when  Its  llgnt  is  green  REQUEST-RED  causes 
S£T-T0( YELLOW) (MY-DIRECTION)  then  SET-TO(RED) (MY-DIRECTION) . 
wnen  its  light  is  green  and  its  approach  is  continuously 
occupied  ano,  after  15  seconds,  the  other  approach  becomes 
occupied  cause  CYCLE. 


MODULE  NAME:  SIGNAL. CONTROL 

PROVIDES:  SET-TO(COLOR) (DIRECTION) 

LOOK-AT(LIGHT) 

REQUIRES!  LIGHT (DIR) (COLOR (ON , OFF) ) 

BEHAVIOR:  Moael  state  (N«S, E-W) (RED, YELLOW, GREEN)  of  light. 
SET-TO  causes  LIGHT(DXRECTION) |B  COLOR. 

LOOK-AT  copies  the  state  of  LIGHT. 


stoplight  control  system  diagram 
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procedure  STOP.light.CONTROL.SYSTEH  is  —  Hein  program 

—  System  Specification 

type  DIRECTION  is  (N.S,£.n);  --  SO L 

oaekage  detector  is 

tasx  type  DETECTOR.TASK  f 
DETECTORS array (DIRECTION) of  DETECTOR.TASK ; 

--  Detects  vehicles  in  the  approach  to  the  interaectlon  and 
--  signals  the  approach  controller  in  its  direction  when  the 
--  approach  becomes  occupied  or  empty* 

—REQUIRES!  LANE. OCCUPIED ,  LANE.EMPTY 
end  DETECTOR; 

package  APPROACH  is 

tyoe  Lane  Is  (EMPTY, OCCUPIED); 
task  type  CONTROL.TASK  is 

entry  LANE.OCCUPIED;  —interrupt, 
entry  LANE.EMPTY;  —interrupt, 
entry  LOOK.AT(Ltout  LANE); 

entry  CYCLE;  —Behaves  like  EMPTY  followed  by  OCCUPIED. 

—  OCCUPIED  causes  a  request  for  a  green  light. 

—  empty  causes  a  request  for  a  rad  light, 
entry  INITIALIZE.TO(DIR;in  OIRECTION); 
end  CONTRUL.TASK; 

CONTROL; array (DIRECTION) of  CONTROL.! ASK ; 

for  CON TROL( DIRECTION 'FIRST ) .LANE.OCCUPIED  use  at  *| 
for  CONTROL (DIRECTION 'LAST ) .LANE.OCCUPIED  use  at  12; 
for  C0NTR0L(DIRECT10N'PIRST).LANE.EMPTY  use  at  16; 
for  CONTROL (DIRECTION 'LAST ) .LANE.EMPTY  use  at  20; 

—REQUIRES!  REQUEST.GREEN;  REQUEST.RED; 

end  approach; 

package  INTERSECTION  is 

task  type  CONTROL.TASk  Is 
entry  REQUEST.RED; 
entry  REQUEST.GREEN; 

entry  LOOK.AGAIN;  «—  look  at  the  light  and  the  intersection  aqain. 
entry  INlTIALIZE.TO(DIRlln  DIRECTION); 
end  CONTROL.TASK; 

CONTROL; array (DIRECTION) of  CONTROL.TASK; 

—  Provides  green  lights  to  occupied  roads  and  red  lights  to 
—  empty  roads  while  alternating  whan  neeessary. 

—REQUIRES!  LOOK.AT(LIGHT) ;  LOOK.AT(LANE) ;  SET.TO(COLOR) (DIRECTION) ; 

—  CYCLE;  OTHER.DIRCCTION. LOOK.AGAIN; 

end  intersection; 


package  signal  is 

type  COLOR  is  (RED, YELLOW, GREEN) ; 

for  COLOR  use  f RED*>2» 1009 ,YELL0Wa>2 1010# ,GRCENm>2S00t I) ; 
>  type  STOP.LIGHT  is  array(DlRECTION)  of  COLOR; 

LIGHT ; STOP.LIGHT 1 ■ ( RED , RED ) ; 

for  LIGHT  use  at  76; 
task  CONTROL  is 

entry  S£T.TO(CQLQR)(OIR«ln  DIRECTION); 
entry  LOOK.AT(L;out  STOP-LIGHT); 

—  SETs  light  in  one  direction  to  red, yellow  or  green 
—  while  setting  other  direction  to  red. 
end  control; 


—Includes  the  module  LIGHT  from  wnieh  it 
— REOUIRCS ! LIGHT (DIRECTION, COLOR ( ON , orP ) ) ; 
•f* d  ArfidiM. 


—  End  Specification 


package  body  DETECTOR  Is  **6001;)  system  Implementation 

--  Hardware. 

end  DETECTOR  I 


package  body  APPROACH  Is 
task  body  CONTROL-TASK  Is 
MI-LANE: LANE  :«£MPTIf 
MY.DIRS DIRECTION I 

begin  —  APPROACH. CONTROL-TASK 

accept  INITIALIZE— TOC MI.DIR: in  DIRECTION);  —learn  my  direction 
loop 
select 

accept  look. AT(L: out  LANE)  do 
l:«my.lanei 

end; 

or  accept  lane-OCCUPIED  do 
mY-LANE:«OCCUPIED; 

INTERSECTION. CONTROL(HY-DIR) .REQUEST-GREEN; 
end; 

or  accept  lane.Empti  do 
my.lanejsempty; 

INTERSECTION. C0NTR0LCMY-DIR).RE0UEST-RED| 
end ; 

or  accept  CYCLE;  —simulate  break  In  steady  stream  of  traffic. 
If  MY.LANEXOCCUPIED  then  —  if  necessary. 

INTERSECTION. CONTROL(MY-DIR) .REQUEST-REDl 
I NTERSECTI ON . CONTROL ( MY— DIR) . REQUEST-GREEN ; 
end  if; 
end  select; 
end  loop; 
end  CONTROl.TASK; 
end  approach; 


package  body  INTERSECTION  is 
task  body  CONTROL.TASK 
WY.0IR:DIRECTIQN; 

OTHER— DIR {DIRECTION; 

OTHER-LANE* APPROACH. LANE; 

LIGHT tSIGNAL. STOPLIGHT; 

begin  —  INTERSECTION. CONTROL-IASK 

accept  INiTlALIZE.TOCMY.DIRtln  DIRECTION)  do  —learn  my  direction 
if  MY-DIRsDIRECTION'LAST  then 
OTH£R.DIR:*DIRECTIOft 'FIRST; 
else 

OTHER.DIR*BDIRECTION'SUCC(MY.DIR); 
end  if; 

end  INITIALIZE-TO; 
loop 

SIGNAL. CONTROL. LOOK-AT(LIGHT); 
select 

wnen  lightered, red)  » 

accept  REQUEST-GREEN  do 

SIGnAL.CONTROL.SET-TO(GREENHMY-DIR); 

I NTERSECTI ON • CONTROL ( OTHER-DIR ) » LOOK.AG AI N ; 
end; 

or  when  LIGHT(my-DIR)>RED  •>  --  catch  extra  red  reauests 
aceeot  REQUEST-RED; 


or  When  LIGHT ( M Y-DIR )bGREEN  s> 
accept  REQUEST-BED  do 

SIGNAL. CONTROL. SET-TO (YELLOW) (MY-DIR) S 
delay  3*SECONDS; 

SIGNAL. CONTROL. SET-TO(RED) (MY-DIR); 
INTERSECTION. CONTROL ( OTHER-DXR ) .LQOK.AGA1N; 
end; 

or  when  LIGHT(MY-DIR)*GREEN  «> 
delay  15*SECONDSf 

APPROACH. CONTROL(OTKER.OIR) .LOOK-AT(OTHER-LANE) ; 
If  OTHER.LANEbOCCUPIED  then 

APPROACH. CONTROL(MY.OIR) .CYCLE; 
end  If; 

or  accept  LOOK-AGAXN; 
end  select; 
end  loop; 
end  CONTROL-TASK; 
end  INTERSECTION; 

package  SIGNAL  Is  > 

taste  body  CONTPOL  Is 

beam  —  SIGNAL. CONTROL 
loop  .*• 

select 

acceot  LOOK— AT(L:oUt  LIGHT)  do 
LIbLIGHT; 
end; 

or  when  LIGHT* (RED, RED)  •> 

accept  SET-TO(GREEN) (DIRl  In  DIRECTION)  do 
LIGHT(DIR)|bGRCEN; 
end; 

or  accept  SET.TQ(YELLOW) (OIRlln  DIRECTION)  do 
LIGHT(OIR)|sYELLO*; 
end; 

or  accept  SET-TO(RED) (DIRtin  DIRECTION)  do 
LIGHT(OIR);bred; 
end;  . 

end  select; 
end  loop; 
end  CONTROL; 
end  signal; 


beam  —  stop-light-control-system  Main  program 

tor  PIP  In  DIRECTION  loop  --ma*e  controllers  aware  of  their  directions 
APPROACH  .CONTROL (DIR)  ,  INITIALIZE-TO(DIR)  t 
INTERSECTION. CONTROL(DIR) .INITIALIZE-TO(DIR) ; 
end  loop; 

end  STOP-LXGHT.CONTROL.SYSTEM;  —  End  System  Implementation 


APPENDIX  II. 


SYSTEM  DESIGN  LANGUAGE 
SYNTAX  INFORMATION 


SYNTAX  SUMMARY 

compilation  i :■  {compilation-unit) 

comclletion-unit  :i*  {WITH  unlt.namel, unit-name) > subprogram. declaration? 

I  {with  unlt-name{,unit-narDe>)subprogram-body; 

I  {WITH  unlt.namel, unit-name) )package-declaration; 

I  {with  unit-name{, unlt-name) ) package-body; 

I  {WITH  unlt-name{,unlt-name>)suounlt; 
Subprogram-declaration  :ts  procedure  Identifier (formal-part) 

I  function  identifier (formal.part) RETURN  type 
subprooram-body  s subprogram.declaration  IS 

(declarative-item) 

BEGIN 

{statement) 

END 

package-declaration  ) : =  PACKAGE  identifier  IS 

<deelaritive-item) 

[PRIVATE 

(declarltlve.ltem)) 

END 

oacKage.body  j**  PACKAGE  BODY  Identifier  IS 

(declarltive-item) 

[BEGIN 

{statement)) 

END 

subunit  SEPARATE(unlt.name)  subunit-body 
rtecieratlve-ltem  object-declaration 

I  type-declaration 
I  subprogram-declaration 
l  package-declaration 
I  task-declaration 


RATIONAL  AND  USAGE 

In  Ada,  system  structure  bas  two  views:  The  textual  system  structure 
and  the  physical  system  structure.  The  textual  system  structure  is  the 
textual  layout  of  the  program  and  is  portrayed  by  the  systematic  nesting 
of  program  units(packages,  subprograms  and  tasks)  within  declarative 
Parts  of  otner  program  units.  Also,  the  specification  of  a  program  unit 
(le.  its  oenavlor  definition)  is  textuaily  separate  from  the  body  of  that 
Program  unlttie.  its  implementation).  This  textual  structuring  of  the 
system  accomplishes  tn*  grouping  of  semantically  related  units  and 
controls  the  scope  of  names  in  the  system. 

The  physical  system  structure  is  tne  grouping  of  program  units  into 
compilation  units.  Each  program  unit  specification  and  body  is  a 
compilation  unit  and  is  compilable  separately  from  the  other  compilation 
units.  The  visibility,  or  allowed  usage,  of  items  declared  in  other 
compilation  units  must  oe  provided  explicitly,  using  a  wITH(other-unlt) 
clause,  in  a  compilation  unit.  This  allows  precise  control  of  the  names 
usable  in  a  unit. 


The  textual  structuring  mechanism  provides  the  basic  control  of  the 
visibility  of  named  entitles  via  nesting  and  separation  of  behavior  from 
lmoilmentatlon,  wnile  the  pnyslcal  structuring  mechanism  provides  the 
additional  capability  of  explicit  control  of  the  dependencies  of  units 
on  other  units  whicn  are  textualy  visible  to  the  unit, 

Textually,  a  system  in  Ada  Is  normally  presented  as  a  procedure, 
giving  a  name  to  the  .system,  which  has  a  (large)  declarative  part.  The 
declarative  part  consists  of  types  and  objects  global  to  the  system,  a 
seouenee  of  package  specifications  which  define  the  components  of  the 
system  and  a  sequence  of  package  bodies  which  implement  the  components. 
The  (small)  sequence  of  statements  of  the  "main"  procedure  serves  to 
Initialize  the  components  and  start  the  operation  of  the  system. 

For  example,  textually  a  system  appears  like  the  following: 

procedure  SYSTEM  Is 
tyoe  GLOBAL-TYPES  is 
OBJECT:  TYPE; 

•  •  • 

package  FIRST  is 
type  ... 

OBJECTS  ... 

procedure  specifications 

function  specifications 
end  FIRST; 
package  SECOND  Is 

end  SECOND; 
packaqe  THIRD  Is 

end  THIRD; 

package  body  FIRST  is 
type  ... 

OBJECTS  ... 
procedure  bodies 
(  * 

function  bodies 
end  FIRST; 

oackaqe  body  SFCOND  is 

end  SECOND; 
package  body  third  is 

end  THIRD; 

beam  ••  sequence-of-statements 
initialize; 
start; 

end  SYSTEM; 


Layered  on  too  of  this  textual  atructure  la  the  phyalcal  atructura 
of  compilation  units.  This  provides  three  advantages  not  possible  with 
just  textual  structuring! 

separability  of  the  development  of  components  from  one  another* 
tnereoy  allowing  the  development  of  components  in  parallel. 

Increased  control  of  the  development  of  the  system*  since  the 
desi oner  nas  control  of  the  design  (specification  parts}  while  the 
programmers  have  control  of  only  their  component's  Implementation. 

Increased  clarity  In  the  design*  slnee  dependencies  among  modules 
are  made  explicit  by  the  use  of  "with"  clauses. 

The  above  example  can  be  divided  into  compilation  units  In  either 
of  the  following  two  waysi  (dashed  lines  separate  compilation  units) 

collection  of  units  unit  with  subunits 


package  GLOBAL  Is 
tyoe  GLOBAL  .. 
OBJECTS {GLOBAL  .. 


with  (GLOBAL) 
package  FIRST  Is 

end  FIRST; 


with  (GLOBAL, FIRST) 
package  second  is 

end  second; 


with  (GLOBAL .SECOND) 
procedure  system  is 

end  system; 


package  body  FIRST  Is 
•  •  • 

end  FIRST; 

package  body  SECOND  Is 
end  second; 


procedure  SYSTEM  Is 
type  GLOBAL  .. 

OBJECTS; GLOBAL  .. 
package  FIRST  Is 

,  end  FIRST; 

package  body  FIRST  Is  separate; 
package  SECOND  is 

end  second; 

package  body  SECOND  Is  separate; 
begin 

end  SYSTEM; 


separate  (system) 
peekege  body  FIRST  Is 

end  FIRST; 


separate  (SYSTEM) 
package  body  SECOND  Is 

end  SECOND; 


Both  of  these  have  the  seme  textual  nesting  out  the  physical 
layout  of  tne  first  (collection  of  units)  Is  more  fiexlole  and  oetter 
controls  the  dependencies  of  components  (packaoes)  uoon  one  another* 
whereas  tne  second  (units  with  subunits)  provides  an  exposition  of 
tne  textual  structure  of  the  system  In  a  single  package  (le.  system). 
Large  systems  win  probably  benefit  more  from  the  first  style  due  to 
Its  tionter  control  of  structure  end  greeter  potential  for  parallelism 
in  development  wnereas  smell  systems  may  benefit  from  tne  ease  of 
menacing  the  design  within  one  unit  provided  by  the  second  style. 


Tasks  are  proaram  units  but  they  are  not  compilation  units.  Since 
most  embedded  computer  systems  will  need  to  use  tasklno,  the  ability 
to  provide  tasks  as  compilation  units  can  be  accomplished  as  follows: 

The  task  type*  its  needed  type  definitions  and  the  task  object(s) 
are  declared  in  tne  specification  part  of  a  package  wnose  sole  purpose 
is  to  encapsulate  the  task.  The  package  is  then  viewed  as  the  component 
and  tne  body  of  tne  task  can  be  separately  compilable  by  maxing  it  the 
subunit  of  the  package  specification.  For  example: 


packaae  PACKAGE.NAME  is 
types  ... 

task  tyoe  task.type.name  is 
entry  FIRST; 

end  TASkItyPE.NAME; 

task  body  task.type.name  is  separate; 

TASK.OBJECTSxTASK.TYPE.NAME; 
end  PACKAGE.NAME; 


separate  (PACKAGE-NAME) 
task  body  TASK.TYPE.NAME  is 

end  taskItypE-NAME; 


